The IEEE Recommendation 802.16e presents a new method of power-saving for mobile as well as stationary wireless terminals named sleep-mode. Using the sleep-mode method, terminals can operate in a virtually infinite sequence of listening and sleeping windows, where during listening windows the terminals operate in a normal-mode while during sleeping windows the terminals cannot transmit data and do not expect to receive data, hence they can implement power saving scheme during this time window.
Sleep-mode is aimed to support various traffic patterns and applications, such as unicast and multicast services, VoIP, web traffic, etc. It includes three types of power-saving schemes: one with increased sleeping windows, a second with constant sleeping windows, and a third with a single sleep window operation. In addition, the sleep-mode defines triggers for automatic self deactivation: such as BW request and data transfer during the sleep-mode operation.
For mobile and stationary wireless terminals Sleep-mode is operated using the definition of activation and deactivation of Power Saving Class(es) (hereinafter “PSC”). Every PSC defines a type of operation (from among the three possible scheme types described above), the associated connections, the operating sequence (sleeping and listening windows), and the automatic deactivation triggers. When a PSC is first defined, it is given a unique 6 bits ID, named Power_Saving_Class_ID. By using the Power_Saving_Class_ID, both the terminal and the associated Base Station (BS), may activate and deactivate the PSC, and re-define it.
As mentioned above, sleep-mode operation can be activated and deactivated by either side of the communication link, (i.e. either by the BS or by the terminal). In such a case, the terminal would transmit a MOB_SLP-REQ message, requesting information that concerns the activation, definition and deactivation of a certain PSC. Upon receipt of the request message, the BS responds by sending a MOB_SLP-RSP message, indicating to the terminal whether the request has been approved. On its part, the BS can also transmit to the terminal a MOB_SLP-RSP in an unsolicited manner, instructing the terminal to activate or deactivate a certain PSC, defining a new PSC, or re-defining an existing PSC.
Due to the nature of the protocol (both request-respond transaction and unsolicited response transaction), taken together with the unreliable characteristics of the wireless interface, it is possible that definitions and re-definitions packets will be lost. Therefore, it is possible that the BS and terminal hold different views of the PSC definitions. Consequently, when the PSC is activated the BS holds and maintains a different windows sequence than the terminal. This scheme synchronization problem might cause the BS to send data to the terminal when the latter is in a sleeping window, which in turn would lead to loss of data, and ultimately resulting in degradation of the BS's performance.
IEEE recommendation 802.16e defines the concept of sleep-mode but does not provide a proper solution to the synchronization problem described above.
WO 06/040769 describes a method for carrying out a power saving procedure in a terminal receiving a number of different services, each belonging to a different PSC. The method comprises determination of required listening windows and required sleep windows for each of the power saving classes, and calls for exchange of messages between the base station and the terminal for synchronizing parameters in order to carry out a power saving procedure.
In IEEE Recommendation 802.16d/e some MAC messages, such as: UCD, DCD, and MOB_NBR-ADV, include a parameter named Configuration Change Count (CC) that ensures proper terminal tracking of the BS configuration changes. By this mechanism the BS increment the CC upon changes in its configuration and transmit the new value in the next UCD and DCD messages. The terminal can then compare the CC value with the one stored in its memory to verify if its configuration parameters are up-to-date.